Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.254

Text File | 1996-02-12 | 27.9 KB | 654 lines

Frequently Asked Questions (FAQS);faqs.254



! GB02 All programs need to use the same algorithm elm(1)    and
!      frm(1) use    in establishing    the user's id and the user's in-
!      coming mailbox.

- GB10 [next item    goes here]

! 2.  Elm(1) bugs

- EB02 Encryption    is not fully implemented in ELM.  In elm(1) we
-      have the following    problems:

!      When `b' (bouncing) a message or `f' (forwarding) a message
!      without editing, an encrypted section of text in the origi-
!      nal message wrongly gets encrypted    a second time.    The func-
!      tion that looks for encryption delimiters needs to    know to
!      ignore them in these situations.

-      When `p' (printing) or `|'    (piping) a message, an encrypted
-      message does not get decrypted.  This is because elm(1) in-
-      vokes readmsg(1) to pull the message out of the folder and
-      readmsg(1)    does not deal with encryption at all.  Even if we
-      gave readmsg(1) the ability to decrypt messages, we'd still
-      have problems because readmsg itself would    have to    prompt
-      for the decryption    key.  Now if we    were printing or piping    a
-      set of tagged messages, readmsg(1)    would have to prompt for
-      decryption    keys for each message individually.  In    doing
-      that readmsg(1) would have    to indicate which message of the
-      set it was    working    on.  This would    be difficult since
-      readmsg(1)    uses actual ordinal message position in    the fold-
-      er, and that would    be confusing if    the user has folders
-      sorted in other than mailbox order: the message numbers
-      wouldn't match up.     The solution therefore    involves replac-
-      ing readmsg(1) with a new function    in elm(1) to handle the
-      `p' or `|'    commands, and this function would need to detect
-      the encryption delimiters and prompt for the decryption key.
-      Furthermore, readmsg(1) should get    enhanced to deal with en-
-      crypted text, or else carry a disclaimer that it doesn't
-      work on encrypted text.

-      When including the    text of    an original message for    a `r'
-      (reply) or    `f' (forward), encrypted sections do not get de-
-      crypted first, resulting in decrypted text    inside the in-
-      clude text.  This means that the elm(1) function that in-
-      cludes text of an original    message    must detect encryption
-      delimiters    and decrypt encrypted text before including it in
-      a reply or    forwarded message.

! EB26 When using    an address of the form "node!user@domain" and
!      having Elm    convert    it to an all ! address,    RFC976 states
!      that the proper address should be domain!node!user, but Elm
!      translates    that to    node!domain!user.

- EB36 When Elm is configured not    to look    at the password    file for
-      full name information, it sometimes places    the user name in
-      ()s as the    comment    in addition to the full    name.

! EB41 [next item    goes here]

! 3.  Utilities bugs

! UB02 Newmail(1)    displays a null    "From" when a message does not
!      contain a From: header line.  It needs to be able to parse
!      the return    path and display the "last two words" of it, just
!      like elm(1) does  when it encounters a message without a
!      From:

! UB07 Arepdaemon    has a bad security hole    because    it does    not check
!      to    see if the user    can read the file used for reply.

! UB09 Autoreply.c tries to unlink the file "/etc/autoreply.data"
!      when there    is only    one entry in it    and does not check the
!      return value of unlink.  This can have bad    repercussions if
!      the unlink    fails because the program nevertheless reports
!      success.

! UB13 If    filter is run on a system that allows multiple delivery
!      agents, that can start up multiple    copies of filter,
!      delivery of messages can get intermixed.  Filter needs a
!      complete interlocking to prevent this.

! UB14 [next item    goes here]



--- 260,501 ----
  change is to fix it, and what else it ties into in the 3.0 work).
  Items marked fixed will be deleted from the list on the next posting.


! Database last updated on Thursday  3-December-92 14:52:04 +0000 (GMT)

! General bugs and configuration bugs
! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


! GB01  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Configuration questions need rearranging
!       Description:
!           The ordering of some sets of configuration questions could be
!           improved.  In some cases, the answer to a later question
!           renders an earlier question moot.  In such cases, the latter
!           should proceed the former so that the former would only be
!           asked if need be.  This occurs with many of the configuration
!           questions that deal with the domain routing and pathalias
!           databases, appending the hostname and internet address style,
!           etc.


! GB02  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     User id & mailbox algorithm should be consistant.
!       Description:
!           All programs need to use the same algorithm elm(1) and frm(1)
!           use in establishing the user's id and the user's incoming
!           mailbox.



! Elm(1) bugs
! ~~~~~~~~~~~


! EB02  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Encryption is not fully implemented in ELM.
!       Description:
!           In elm(1) we have the following problems:

!           When `b' (bouncing) a message or `f' (forwarding) a message
!           without editing, an encrypted section of text in the original
!           message wrongly gets encrypted a second time. The function
!           that looks for encryption delimiters needs to know to ignore
!           them in these situations.

!           When `p' (printing) or `|' (piping) a message, an encrypted
!           message does not get decrypted. This is because elm(1) invokes
!           readmsg(1) to pull the message out of the folder and
!           readmsg(1) does not deal with encryption at all.

!           Even if we gave readmsg(1) the ability to decrypt messages,
!           we'd still have problems because readmsg itself would have to
!           prompt for the decryption key.

!           Now if we were printing or piping a set of tagged messages,
!           readmsg(1) would have to prompt for decryption keys for each
!           message individually. In doing that readmsg(1) would have to
!           indicate which message of the set it was working on.

!           This would be difficult since readmsg(1) uses actual ordinal
!           message position in the folder, and that would be confusing if
!           the user has folders sorted in other than mailbox order: the
!           message numbers wouldn't match up. The solution therefore
!           involves replacing readmsg(1) with a new function in elm(1) to
!           handle the `p' or `|' commands, and this function would need
!           to detect the encryption delimiters and prompt for the
!           decryption key. Furthermore, readmsg(1) should get enhanced to
!           deal with encrypted text, or else carry a disclaimer that it
!           doesn't work on encrypted text.

!           When including the text of an original message for a `r'
!           (reply) or `f' (forward), encrypted sections do not get
!           decrypted first, resulting in decrypted text inside the
!           include text. This means that the elm(1) function that
!           includes text of an original message must detect encryption
!           delimiters and decrypt encrypted text before including it in a
!           reply or forwarded message.
!
!
! EB26  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Addresses "node!user@domain" not handled as RFC976
!       Description:
!           When using an address of the form "node!user@domain" and
!           having Elm convert it to an all ! address, RFC976 states that
!           the proper address should be domain!node!user, but Elm
!           translates that to node!domain!user.
!
!
! EB36  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Sometimes user name is added into full name field
!       Description:
!           When Elm is configured not to look at the password file for
!           full name information, it sometimes places the user name in
!           ()s as the comment in addition to the full name.
!
!
! EB41  Version:     2.3PL11          Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Rob Price)
!       Summary:     Incoming mail incorrectly handled in subset mode.
!       Description:
!           If a subset of mail is displayed using the "l" command, new
!           incoming mail is displayed with the subset mail.  However the
!           mail count at the top of the screen is not updated, and the
!           final few items (ie those numerically after the number of
!           messages shown) cannot be selected by the cursor keys.
!
!
! EB42  Version:     2.4PL3           Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Jim Moore)
!       Summary:     Builtin editor unable to delete back over line boundary.
!       Description:
!           The builtin editor is unable to delete back over a line
!           boundary.  Attempts to delete back over a line boundary can
!           cause the whole message to be lost, and unpredictable effects
!           to be seen on screen and possibly garbage characters in the
!           file.
!
!
! EB43  Version:     2.4PL3           Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Andrew Cytron)
!       Summary:     Elm does not enforce newline at end of message.
!       Description:
!           Some MTAs (notably Sun sendmail) require that the message end
!           in a newline character.  Elm does not enforce this, which can
!           result in the MTA failing or hanging.
!
!
! EB44  Version:     2.4PL6           Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Marc Pawliger)
!       Summary:     Builtin editor treats "/" as white space char.
!       Description:
!           The builtin editor treats "/" as a whitespace character and
!           performs wordwrap (including deleting the "/") on things such
!           as file names.
!
!
! EB45  Version:     2.4devPL65       Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Joe Greco)
!       Summary:     Incoming messages can confuse the index screen display.
!       Description:
!           Elm can lose track of incoming (new) messages so that although
!           the number of messages at the top of the screen is correct,
!           the new messages are not displayed on the index page.  However
!           these messages can be accessed in the normal way, they just
!           aren't listed in the index.  Redrawing the screen restores
!           things to normal.
!
!
! EB46  Version:     2.4PL13          Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (J. Philip Miller)
!       Summary:     To: addresses split over lines can confuse group reply.
!       Description:
!           If an address in the To: part of a message is split over more
!           than one line, a group reply to that message will incorectly
!           parse the addresses and build an incorrect Cc: header.
!
!           The example given had the fullname part of an address in ()
!           split onto a continuation line.  In this case elm added 2
!           additional addresses into the Cc: line - made up of the 2
!           parts of the full name each with the original senders domain
!           name suffixed on.
!
!
! EB47  Version:     2.4PL13          Status:     Open
!       Open Date:   3-Dec-92         Close Date:
!       Reported by: morwyn![e-mail] (Forrest Aldrich)
!       Summary:     Only last line of each header can be edited
!       Description:
!           The header editor only allows the editing of the last screen
!           line of a header.  Backing up to previous lines is not
!           possible.
!
!
!
! Utilities bugs
! ~~~~~~~~~~~~~~
!
!
! UB02  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Newmail cannot handle null From: headers.
!       Description:
!           Newmail(1) displays a null "From" when a message does not
!           contain a From: header line. It needs to be able to parse the
!           return path and display the "last two words" of it, just like
!           elm(1) does  when it encounters a message without a From:
!
!
! UB07  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Arepdaemon does not check user permissions.
!       Description:
!           Arepdaemon has a bad security hole because it does not check
!           to see if the user can read the file used for reply.
!
!
! UB09  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Arepdeamon does not check status when unlinking data file.
!       Description:
!           Autoreply.c tries to unlink the file "/etc/autoreply.data"
!           when there is only one entry in it and does not check the
!           return value of unlink. This can have bad repercussions if the
!           unlink fails because the program nevertheless reports success.
!
!
! UB13  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Filter has no locking against multiple instantiations.
!       Description:
!           If filter is run on a system that allows multiple delivery
!           agents, that can start up multiple copies of filter, delivery
!           of messages can get intermixed.  Filter needs a complete
!           interlocking to prevent this.
!
!
! -- end of elm bug database



--
========================================================================
Sydney S. Weinstein, CDP, CCP          Elm Coordinator - Current 2.4PL17
Datacomp Systems, Inc.                 Projected 3.0 Release: ??? ?,1994
[e-mail] or dsinc!syd      Voice: [phone], FAX: [phone]
Xref: bloom-picayune.mit.edu comp.mail.elm:8534 news.answers:4590
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!news.bbn.com!olivea!spool.mu.edu!dsinc!dsinc!not-for-mail
From: [e-mail] (Syd Weinstein)
Newsgroups: comp.mail.elm,news.answers
Subject: Monthly Elm Posting from the Elm Development Group
Keywords: monthly elm posting
Message-ID: <[e-mail]>
Date: 15 Dec 92 01:46:51 GMT
Expires: +1 month
Sender: [e-mail]
Followup-To: poster
Organization: Datacomp Systems, Inc., Huntingdon Valley, PA 19006
Lines: 615
Approved: [e-mail]
NNTP-Posting-Host: dsinc.dsi.com

Archive-name: elm-monthly/part1

This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator.  Please send all questions and comments about
this posting or Elm itself to [e-mail] (dsinc!elm).  See the
README section of this posting for info on some Elm 2.4 FAQ's.
This posting generated:
Mon Dec 14 20:46:08 EST 1992

Current release version: Elm 2.4 PL17
    This version was released at patch level 0.
    comp.sources.unix Posting-number: (Not yet posted)
    Archive-name: (Not yet posted)
    Patches are posted to comp.sources.bugs and comp.mail.elm
    After they are stable, patches are sent to comp.sources.unix
        The following patch sets have been posted, 1/2, 3, 4/5,
            6, 7/8, 9/10, 11, 12/13, 14-17.
        Archive-name: (No patches yet posted to comp.sources.unix)
    Patches are available from the archive server at DSI.COM:
    send mail to [e-mail]
    send elm index

Note: the archive server will not respond to users names root, daemon,
postmaster or mailer-daemon.  Please use your own login when requesting
information from the archive server.

Planned next version: Elm 3.0
    Current Elm 3.0 status: Development expected to start 1/1/93
    Expected release date: Sometime in 1994.

As of release 2.1, Elm is now being developed by a cooperative venture
of volunteers loosely being called the Elm Development Group.  There are
approximately 40 developers and an additional 16 testers, participating
at various levels of activity.

Comments, bug reports, feature requests, etc.  should be sent to
[e-mail].  I try to ack most reports, but over 60% fail due to
invalid addresses.  Note, I strip your address to name@fqdn or name@site
before replying.

New releases will be posted to comp.sources.unix, patches will be posted
to comp.sources.bugs.  After patches have been proven and out for a
while, they will be posted to comp.sources.unix.  Patches are available
from the archive server at DSI.COM.  The complete release as of the
current patch level is available via anonymous uucp from dsinc.  Also
available via anonymous uucp are postscript output files of the current
documentation.  This service is provided for those sites that have
postscript but do not have di-troff.  Instructions for obtaining files
via anonymous uucp from dsinc are also available from the archive
server.  Elm is too large to mail, don't bother asking.  Also don't
mail me asking for me to send you patches, I won't.  Use the archive
server.  The archive-server will not respond to users named root,
daemon, or postmaster to prevent loops.  Please do not use those names
for archive requests.  PLEASE do not send archive requests to [e-mail].

The following sites have agreed to make Elm available via anonymous ftp.

    Site            Contact
    In the US/Canada:
    wuarchive.wustl.edu    David J. Camp, [e-mail]
          (128.252.135.4)

    ftp.uu.net
      (137.39.1.9, 192.48.96.9)

    In Europe:
    ftp.cs.ruu.nl        Edwin Kremer, [e-mail]
    (131.211.80.17)

    In the UK:
    uk.ac.soton.ecs        [e-mail] (bitnet)
    (152.78.64.201)            [e-mail] (JANET)

        In Australia:
        ftp.adelaide.edu.au     Mark Prior, [e-mail]
          (129.127.40.3)

    In Taiwan:
    NCTUCCCA.edu.tw        Huang, Chih-Hsien [e-mail]
    (140.111.3.21)


The following sites have agreed to make Elm available via anonymous
uucp:
    Site            Contact
    uunet            Elm is /networking/mail/elm

    dsinc            Syd Weinstein
                [e-mail], dsinc!syd
                note: anon uucp info changed 12/16/91
                For further info, send an e-mail
                message to [e-mail] stating:
                send anon how-to dir


    stanton            Steven P. Donegan
                [e-mail], stanton!donegan
                714-894-2246 uucp - nuucp no word
                Elm is /u/public/elm2.3.tar.Z


-----------------------------README SECTION-----------------------------
First: See the README file that is part of the Elm Source Distribution.
Many questions might be answered there.

Where do I get the "Elm Reference Guide", "Elm Users Guide", ...
    Elm has several documents (over 100 pages worth of doc)
    that were written to help users install, support and use Elm.
    These are in the doc directory of the source distribution.
    Contact your systems administrator for a copy of the documents.
    For those sites that do not have troff (either di-troff or
    o-troff) and do have postscript printers, dsinc (dsinc.dsi.com)
    has a copy of the docs already in postscript format available
    for anonymous uucp or ftp.

Why do I get the remote signature on replies to local mail?  Can I
define what addresses are local?
    In Elm 2.4, any address with an ! or @ in it is considered
    remote, without those characters, its local.
    Any reply is qualified to prevent alias expansion.  If you had
    an alias in your private Elm aliases that matched the name of a
    user on your system, but that alias did not point to that user,
    there would be no way to reply to the message.  It would end up
    going to the alias name, not the user that mailed you.  To
    prevent this, Elm fully qualifies (adds the site name) to a
    reply address.  This makes the simplistic signature detector
    think that the message is 'remote'. This is not slated to
    change until 3.0.

Why Elm adds your local hosts qualification to reply addresses:
(Or why the DANGER WILL ROBINSON KLUDGE is in the code)
    Elm passes any address off to the alias mapper to see if it
    needs expansion.  If you are replying to a bare user name of
    abc, Elm converts it to [e-mail] (assuming internet
    addressing, myhost!abc for the rest).  This is to prevent the
    alias expansion.  If you were to have, in you private Elm alias
    table an alias of abc that pointer to
    [e-mail], if the address wasn't qualified,
    Elm would convert the reply to abc to go to
    [e-mail].  This is generally not what you
    want :-)

If you can guarantee that no private alias will ever match a local user
name on your system, then you can disable the kludge code.  The kludge
will have to remain until 3.0 when Elm will track whether an address
has been/should be expanded, and its prior to and after expansion values.
In 2.x it doesn't do that.

How can I get elm to NOT expand the alias list on outgoing msgs?
Problem is if a list has, say, 100 names in it then sending to the list
expands every single one of the 100 names. I would like the message to
have the "To" line = the name of the list itself and have the actual
recipients' names not appear.
    You can't and don't want to. (and yet you can also) An alias is
    a mechanism of making Elm address a message to multiple
    people.  However, when the message gets to its destination, Elm
    also has to allow that person do a group reply.  If the message
    only has your local private elm alias in it, the group reply
    will try and go to that alias name.  Unfortunately, that name
    is meaningless to that other person (its private to both Elm
    and you).

    There are two solutions:

    The preferred if replies are desired:
        Have your mail administrator create a file include
        alias for you in your MTA (sendmail, et al).. This is
        usually of the type

    alias    :include:/some/path/to/a/file

    where the file would be in a place you control and you have write access
    to the file.  Then you can add/drop members of the list, and
    the mail just goes to the alias, and, someone sending to
    [e-mail] will be able to send to all members. (group
    reply works correctly)

    The less preferred method: (no group reply is possible)
        Send the message to yourself, with a bcc to the Elm
        alias.
    Of course, the Bcc: won't be expanded by the MTA internal to
    the message, so it won't appear in the message.


From comp.mail.elm, [e-mail] (DaviD W. Sanderson) writes:
>... whoever wrote the default termcap
>and/or terminfo descriptions for xterm included in the ti/te strings
>the special escape sequences to make xterm switch between the normal
>and alternate screen buffers.  These sequences are:
>
>    \E[?47h        - use alternate screen buffer
>    \E[?47l        - use normal screen buffer
>...
>The elm code is just fine as it is.  If you change it so that it
>doesn't ever send ti/te, you'll just break elm for somebody else.  Fix
>your termcap/terminfo definition instead.

Why can't I get SGI to work for non ROOT.....
    SGI, at 3.3, doesn't have vfork, but instead a stub that does
    not work.  Make sure vfork is undef in the configuration.

How do I link Elm on IBM AIX?
    On IBM RISC 6000 AIX, 3.2 or newer, to compile Elm
during Configure, specify -U__STR__ to the 'Additional CFLAGS'
question.  No other changes are needed.

    On IBM RISC 6000 AIX, prior to 3.2, you might get string
funtion errors on the compile.  The solution is to do the following:
    Look at /usr/lpp/bos/bsdsport. It tells you
    to add following lines to /etc/xlc.cfg

    * BSD 4.3 c compiler stanza
    bsdcc:    use       = DEFLT
        crt       = /lib/crt0.o
        mcrt       = /lib/mcrt0.o
        gcrt       = /lib/gcrt0.o
        libraries  = -lbsd, -lc
        proflibs   = -L/lib/profiled,-L/usr/lib/profiled
        options       = -H512,-T512, -qlanglvl=extended, -qnoro, -D_BSD, -D_NONSTD_TYPES, -D_NO_PROTO, -D_BSD_INCLUDES, -bnodelcsect, -U__STR__, -U__MATH__

    And then link bsdcc to xlc and use bsdcc instead of cc.

In addition, Elm should be linked with the curses lib and not termcap lib
if /etc/termcap is not there. (You can always copy the termcap database
to etc (or make a symlink)).


    On 386bsd, the shell that is shipped with the system, ash, does
not work for sending messages within Elm.  Mail messages have headers only
and no body.  Replacing the shell with bash (from GNU) seems to solve the
problem.  The bash shell is in the 'etc' distribution of 386bsd.


Why does my mail to Dave Taylor bounce?
    His new address is limbo!taylor, or, [e-mail]

--END--END--END--END--END----README SECTION----END--END--END--END--END--

Starting with release 2.2, the Elm Development group will attempt to
provide official patches to the release version to fix problems reported
at the same time we are working on the next release.  Also starting with
release 2.2 a list of known problems will be published in this posting.

Known bugs in Elm 2.4 PL13:
    The following are from the Elm 2.4 "To.Do" list that are
considered bugs, not enhancements, that have not yet been done.  Items
which are enhancements are not listed here.  It is our intention to
release changes to 2.4 for some, but not necessarly all of these.  Some
of these will only be fixed in 3.0.  (It depends on how extensive the
change is to fix it, and what else it ties into in the 3.0 work).
Items marked fixed will be deleted from the list on the next posting.


Database last updated on Thursday  3-December-92 14:52:04 +0000 (GMT)

General bugs and configuration bugs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


GB01  Version:     2.4PL0           Status:     Open
      Open Date:   1-Oct-92         Close Date:
      Reported by: Elm Development Group <[e-mail]>
      Summary:     Configuration questions need rearranging
      Description:
          The ordering of some sets of configuration questions could be
          improved.  In some cases, the answer to a later question
          renders an earlier question moot.  In such cases, the latter
          should proceed the former so that the former would only be
          asked if need be.  This occurs with many of the configuration
          questions that deal with the domain routing and pathalias
          databases, appending the hostname and internet address style,
          etc.


GB02  Version:     2.4PL0           Status:     Open
      Open Date:   1-Oct-92         Close Date:
      Reported by: Elm Development Group <[e-mail]>
      Summary:     User id & mailbox algorithm should be consistant.
      Description:
          All programs need to use the same algorithm elm(1) and frm(1)
          use in establishing the user's id and the user's incoming
          mailbox.



Elm(1) bugs
~~~~~~~~~~~


EB02  Version:     2.4PL0           Status:     Open
      Open Date:   1-Oct-92         Close Date:
      Reported by: Elm Development Group <[e-mail]>
      Summary:     Encryption is not fully implemented in ELM.
      Description:
          In elm(1) we have the following problems:

          When `b' (bouncing) a message or `f' (forwarding) a message
          without editing, an encrypted section of text in the original
          message wrongly gets encrypted a second time. The function
          that looks for encryption delimiters needs to know to ignore
          them in these situations.